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Abstract 

Modeling efforts for future space operation vehicles at the United States Air Force 
Research Lab’s Air Vehicles Directorate have been focused towards the in flight mission. 
To better serve the research and development effort, a simulation of the ground 
operations is required allowing for trade-offs within turnaround operations and between 
the components that drive those procedures. However, before a simulation can be 
developed a conceptual model must be generated to guide the model building process. 

This research provides a baseline conceptual model for reusable space vehicles 
based on the space shuttle as the only operational vehicle of its kind. The model is built 
utilizing the Integrated Definition (IDEF) methodology, specifically IDEF3. IDEF3 is 
focused towards process-viewpoint diagramming and layout. The model is developed 
using the hierarchical development capabilities of the IDEF3 methodology and is broken 
into modules allowing for greater reuse and usability. 

This model captures the scheduled maintenance performed to turnaround the 
space shuttle for the next launch but does not contain every activity. The idea was to 
capture the baseline activities that may be found in future Reusable Space Vehicles and 
provide a description of what happens at Kennedy Space Center when preparing the 
space shuttle for the next launch. 
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REUSABLE SPACE VEHICLE GROUND OPERATIONS 
BASELINE CONCEPTUAL MODEL 


I. Introduction 


Overview 

The Air Vehicles Directorate (VA) of Air Force Research Laboratory (AFRL) has 
focused a large portion of its research and development (R&D) towards the development 
of a space operations vehicle (SOV) to support the Air Force’s Global Engagement core 
competency. Simulation based R&D is one tool used by VA to identify technologies 
required to meet Air Force performance requirements. This research will develop a 
conceptual model, the baseline for a simulation that will be utilized to perform trade-off 
studies of alternative system components and aid in the choice of materials. 

In order to develop a model that can be verified and validated, AFRL/VA is 
utilizing the space shuttle and an aircraft similar to the B-2 Spirit Stealth Bomber as 
baselines. The space shuttle is an example of a successful reusable space vehicle (RSV) 
and the B-2 is an example of a system with assets and specialized surface materials 
requiring greater inspection time with a relatively fast turnaround. In order to use the 
space shuttle as a baseline, the model must include processes/activities from landing to 
take-off. The National Aeronautics and Space Agency (NASA) has developed a 
simulation for take-off to landing of the space shuttle, however, NASA’s touchdown to 
take-off (recycling) simulation has insufficient detail to perform technology trade-offs. 
AFRL’s Human Effectiveness Directorate as well as several defense contractors have 
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developed simulations for the recycling of SOVs. Unfortunately, the results of trade-off 
studies vary widely depending upon which alternative was utilized and have not been 
validated against actual systems. Additionally, the simulations have not been developed 
to the detail required by VA in order to conduct the analysis they desire. 

Problem Statement 

In order to develop a detailed simulation for the recycling of the space shuttle, a 
conceptual model must be developed. The conceptual model provides validation of the 
processes that are later transformed into a working simulation (Pace 2002). This research 
will develop a baseline conceptual model for landing to take-off of a generic RSV 
utilizing the space shuttle ground operations as a guide. 

Research Question 

What is the best way to provide an effective conceptual model to support the 
development of a SOV simulation and what space shuttle recycling procedures should be 
modeled? 

Research Scope 

The scope of this research involves baseline examinations that include an 
understanding of conceptual design methodologies. In addition, this study will focus on 
gathering data on current operations for space shuttle turnaround and a review of 
proposed SOVs. This study is limited to the current ground operations and logistics for 
the space shuttle both inside and outside the Orbiter Processing Facility (OPF). 
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Investigative Questions 

In order to address this problem, certain investigative questions were considered. 

1. What is simulation based research and development; how does it relate to 
simulation based acquisition; and how does it support acquisition reform 
initiatives? 

2. Where has the research into RSV development been directed? 

3. Process simulation can be used for analysis but requires modeling to delineate the 
criteria required: What form should this model take and how should it be 
developed. The following sub questions can be used to evaluate this question. 

o What is the purpose of conceptual modeling? 
o What makes a conceptual model? 

o What are the procedures for developing a conceptual model? 
o What are the procedures for verifying and validating a conceptual model? 
o How have conceptual models been used in the past? 
o What graphical/visualization methods can be used for displaying 
conceptual models? 

4. What are the performance requirements for RSVs that drive the detail level 
required for model development? The following sub questions can be used to 
evaluate this question. 

o What procedures comprise ground operations on the space shuttle from 
landing to take-off: what space shuttle operations would be of interest for 
the purpose of developing a generalized model for RSVs? 
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Research into this problem will be directed by a need to answer these questions 
while keeping the overall objective in mind: development of a baseline conceptual model. 
The need to produce a validated conceptual model will be paramount to the ability of the 
model’s usefulness in developing future simulations that can be verified. Additionally, 
an understanding of what components of the turnaround process are important to model 
development will enable the model to be reduced and made as simple as possible. An 
understanding of concepts affecting process flows will be necessary in order to gain a 
better understanding of the operations being examined. In preparing this model, on-site 
observations of operations and their physical make-up and layout will enhance the 
understanding of operational flows for the space shuttle in particular. 

Summary and Conclusion 

This chapter presented background information on and a description of the 
problem being addressed demonstrating the need for research and analysis. A problem 
statement was given along with the overarching research objective used to direct the 
study. Several investigative questions were introduced that will be expanded upon in the 
following chapters. Chapter 2 will present the motivation for developing a conceptual 
model and discuss areas of concern when examining a production or maintenance process. 
Chapter 3 will detail the conceptual model development methodology and present the 
data analysis methodology. Chapter 4 will explain the data analysis and present the 
results in the form of a conceptual model. Chapter 4 will finish with a validation of the 
baseline model followed by Chapter 5 which will provide a brief conclusion and list areas 
of further research for taking this effort to the next level. 
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II. Literature Review 


Introduction 

Much work is being accomplished to determine what the next generation space 
vehicle will be and what systems and components would be best suited to serve in this 
endeavor. NASA is keeping their options open when considering RSVs: either lifting 
body, winged, or capsule design. For VA, the options considered are all winged. With 
the space shuttle being the only operational RSV, an effort to develop a conceptual model 
for RSV ground turnaround procedures would be remiss without heavy concentration on 
the space shuttle operations at Kennedy Space Center (KSC). 

When reviewing the literature, several topics surface that need discussion when 
analyzing any process. These areas are as follows: risk management, scheduling, 
capacity, process management, and layout/location planning. Other areas of interest in 
this research are acquisition reform (to include simulation based R&D and simulation 
based acquisition), future/proposed RSVs, and the space shuttle. After gaining a clear 
understanding of these topics, it is possible to continue this study and develop a useful 
conceptual model for future RSVs based on the space shuttle. 

General Topics 

Risk Management. 

Risk Management is defined by the Software Engineering Institute as a practice 
with processes, methods, and tools for managing risks in a project. It provides a 
disciplined environment for proactive decision making to assess continuously what could 
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go wrong (risks), determine which risks are important to deal with, and implement 
strategies to deal with those risks. 

Additionally, DoD Directive 5000.1 "Defense Acquisition" (Department of 
Defense 2003) mandates a "streamlined management structure and event-driven 
management process that emphasizes risk management.” This includes risks associated 
with worker safety, environmental concerns such as pollution or chemical spills, and 
those associated with material trade-offs that might affect crew or payload safety. 
Additionally, there are concerns for program existence due to mishaps or public opinion. 
Government funding may be lost or private sponsors and stakeholders may loose interest 
or possibly want to distance themselves from the program. Public relations can be a 
significant player in the risk assessment matrix. 

In order to include risk management in the decision making process, one must 
know what the risks are. Several questions can be used to define risks (Cox 2002): 

What is the source of the risk? 

What or who is the target that is at risk? 

What is the adverse effect of concern that the source may cause in exposed 

targets? 

By what causal mechanism, does the source increase the probability of the effect 

in exposed targets? 

Answering these questions will define possible risks to include the source, who or what is 
at risk, the “cost” associated with the risk, and any potential causes. However, risk 
management enters the foray as an external concern. For this study risk management will 
remain in the background without detailed discussion or examination. Risk management 
will be more beneficial when conducting trade-off analysis for various components, 
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systems, and subsystems to be included in whatever RSV is eventually selected. Risk 
management will provide the benefit-to-cost ratio used make judgments upon. Various 
risks and outcomes could be represented as stochastic distributions within a model in 
order to provide a more accurate representation of the real world. 

Scheduling. 

Scheduling can be defined as “the allocation of resources over time to accomplish 
specific tasks” (Krajewski and Ritzman 2001). Conway et al describe scheduling “as the 
task of constructing an ordering of the operations associated with each machine ” 
(Conway, Maxwell et al. 1967). With the latter definition comes the idea of sequencing 
which is said to exist whenever the order of operation between several tasks is a matter of 
choice (Conway, Maxwell et al. 1967). It is clear that many sequencing or scheduling 
problems are solved daily and by everyone; however, many do not see or recognize the 
choices they make as such. When getting up in the morning, there are several tasks that 
are not order dependent—such as brushing teeth, showering, and shaving. Some tasks 
such as brushing hair and showering do require a specific order and are thus a sequencing 
problem. These examples are quite simplistic in nature and do not require much thought 
or planning, but there are more involved problems that have been examined by many and 
use various heuristics or sophisticated algorithms to garner near-optimal or optimal 
solutions. 

Portougal and Robb say that scheduling occurs within various environments with 
four characteristic factors: planning level, production type, production strategy, and 
production cycle time. The planning level refers to the level within the corporate 
hierarchy the planning occurs. Generally, two levels are used formally (company and 
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shop floor) with the aggregate level being conducted informally between the two 
(Portugal and Oliver 1996). Production type refers to relationships between variety, 
volume, and process. The next characteristic, production strategy, refers to the choice 
between make to order and make to stock. Production cycle time is the last 
characteristic, and is the key to determining whether scheduling theory is applicable and 
would be beneficial to planning and scheduling (Portugal and Oliver 1996). 

Based on their research, Portougal and Robb suggest only systems with long cycle 
environments would benefit from scheduling theory applications to the more complex 
nature of processes with cycle times longer than the planning period. When a process can 
be completed within its planning period, scheduling is less complicated and does not 
require the aid of sophisticated algorithms. Portougal and Robb base this conclusion 
partly on the fact that all theoretical scheduling problems assume long-cycle 
environments suggesting a disconnect between what is seen in practice and what is 
proposed and analyzed in research (Portugal and Oliver 1996). 

Scheduling is similar to a job shop method since the operations at KSC involve 
the space shuttle remaining stationary within the OPF with maintenance personnel 
coming to the shuttle. Although the shuttle remains stationary during the maintenance 
effort, some components are removed and taken to other facilities for further processing. 
Much of the scheduling will be constrained by various facilities with limited space, level 
of hazard or risk, and number of personnel or by personnel who perform certain tasks. 

Within a work or process flow is the sequence of operations or tasks guided by 
various constraints. The routing scheme is the path or flow that is followed. This scheme 
can either be mandatory (all steps are prescribed and followed in specific order) or 
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flexible (several alternative flows are allowed as long as the constraints are not violated). 
The shuttle operations would involve a mix of both routing schemes. There are some 
tasks that are prerequisites to others and some that are performed in parallel and others 
that can be performed at any time within the turnaround cycle (Kumar and Zhao 1999). 
Each vehicle is prepped for a preplanned mission and various inspections being 
completed based on the previous mission. An example would be the use of additional 
internal (inside the cargo bay) tanks used by the shuttle to extend missions. Not all 
missions would require the tanks and thus slightly different procedures would be used. 
However, much of the turnaround operations would be the same for every mission 
assuming no unforeseen problems or failures. 

Capacity. 

Scheduling, layout, and resource allocation all have some affect on or are affected 
by capacity. Portougal and Robb list four definitions for capacity that they have 
observed. 


• Design capacity: the maximum output that a production unit (PU) has been 
designed to produce. 

• Effective capacity: the maximum possible output given a particular production 
environment and its accompanying impediments to productivity. 

• Demonstrated (historical) capacity: the typical real-life output rate of a PU. 

• Agreed capacity: the actual capacity negotiated between directors of PU (Portugal 
and Oliver 1996). 


Krajewski and Ritzman (2002) list three types of capacity they call peak capacity 
(maximum output a process or facility can produce under ideal conditions), rated capacity 
(an engineering assessment based on continuous operation with allowance for normal 
maintenance and repair time), and effective capacity (the maximum output a process or 
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firm can economically sustain under normal conditions). Capacity can either be a 
constraint in the case of bottlenecks or can be a tool to limit the affects of variability in 
the case of excess capacity. Sometimes additional resources or capacity are maintained 
for periods of increased demand. Safety stock is an accepted method to protect against 
variable demand or scarce resources during periods where demand fluctuates. For the 
military, this might concern the keeping of certain aircraft or personnel in order to meet 
the requirements of current defense and national security policies. The result here is 
excess capacity and increased costs that require justification during the trade-off analysis. 
Process Management. 

Much of the previous discussion falls beneath the umbrella of process 
management. Process Management is “the selection of the inputs, operations, work 
flows, and methods that transform inputs into outputs” (Krajewski and Ritzman 2001). A 
process is defined as “a series of activities that produce a product or service” (McNeese 
and Marks 2001). Input selection would include make or buy decisions, operations 
selection would involve the choice of process, resources, and layout decisions although 
the latter may be a one time decision. Process management would, however, focus on 
ongoing decisions made on a somewhat regular basis. Process management: 

focuses on the management of processes, not departments 

includes primary, secondary, and work (or sub) processes 

seeks to optimize performance of the entire system 

ensures processes are standardized 

ensures measurements support the vision 

ensures best practices are examined 

focuses on customer satisfaction 

ensures continuous improvement and measurable value 
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represents the way the company is (McNeese and Marks 2001) 


Workflow management involves the coordination and control of processes and 
activities of people and systems in an organization (Kumar and Zhao 1999). Workflow 
management involves information processing and business processes two of three 
activities conducted in a business; the third is material processes. Process management 
would cover the third activity. Although the two seem to be complementary, there are 
many similarities as to how they handle their basic tasks and operations. To some 
degree, workflow management will have its greatest benefit in the feedback loops that 
allow for improved communication. 

Process management has within its scope such techniques as total quality 
management and continuous improvement. There are five common elements of process 
management success (Ittner and Larcker 1997): 

process focus 

human resource management practices 
information utilization 
customer/supplier relations 
organizational commitment 

Process focused management lends itself towards improvement and organizational 
structures based on functions or processes. Human resource management practices that 
lend themselves towards greater training and education as well as a team-oriented 
environment are better suited towards process improvement. Information utilization 
deals with the reduction of variability and waste through the facilitation of problem 
solving. An emphasis on workflow management could enhance the utilization of 
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information. The last two areas deal with improved supply chain relationships and with 


senior leader involvement. The first three items relate more to this research based on its 
process oriented view and the underlying consideration of human resource management 
practices and policies that affect the flow and are not inherently evident. 

Layout/Location Planning. 

When considering location there are several aspects to examine—such as where 
to locate based on resources available, environmental concerns, and type of orbit desired. 
The layout of facilities, and within-facilities, concerns the actual physical layout at the 
chosen location. Depending upon various physical features, the physical layout at a 
chosen location (such as topography) could have significant effect on possible facility 
layout. 

The layout of various work centers and facilities could become the source of 
constraints as well as the lack of available resources due to location choice. According to 
(Krajewski and Ritzman 2001), layout choices can affect: 

flow of materials and information 
utilization of labor and equipment 
customer convenience and sales 
worker safety 
worker morale 
communication 


Four types of layouts are used in general. The first is the product layout in which 
a linear path is used between workstations and departments. This layout is well suited to 
repetitive or continuous production. The second type is the process layout where 
grouping of workstations or departments is accomplished by function. This layout is well 
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suited for low volume environments typical of job shops. In some cases, a mixed or 
hybrid layout is used. This layout combines some aspects of the process and the product 
layouts to achieve operational goals. The last type of layout is the fixed-position layout. 

In the case of the shuttle, only two locations were considered for possible launch 
sites (Vandenberg AFB, CA and KSC) with KSC being the only location ever used. This 
decision was based in part on the facilities already present, but, topography played an 
important role. For these locations, their positions near a large bodies of water where 
launches could take place over non-populated areas and allowed for the possibility of 
easterly orbits from KSC and polar orbits from Vandenberg (Graham and Jones 1982). 

Weather considerations were also considered since poor weather can result in 
delays depending on facility choices and will affect launch and return dates most. Most 
of the assembly occurs within various facilities and structures protected from the effects 
of weather. A real concern at KSC is the hurricane season, though this does not happen 
often enough to drastically affect operations. However, ground ops at KSC would not be 
hindered by weather since assembly occurred out of the elements. 

Acquisition Reform 

The DoD has moved from a bottoms-up to a top-down approach to determine 
capability requirements. The newly released DoD Directive 5000 Series document the 
new approach to system acquisition including emphasis on joint capabilities, teamwork, 
lifecycle cost, and best practices. Acquisition Reform Initiatives support the DoD’s need 
to acquire new capabilities quickly and control/reduce life cycle costs. 
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In order to transition to this new business model, the Air Force developed 
initiatives such as Cost as an Independent Variable, Lightning Bolts, Reduction in Total 
Ownership Cost and Lean Aerospace Initiative. These initiatives present methods to 
reducing total ownership cost, total cycle time, and provide tools to successfully acquire 
new Air Force capabilities quickly at an acceptable cost. 

Simulation Based Acquisition. 

Simulation Based Acquisition (SBA) is a concept where an integrated, 
collaborative process is used for planning and execution of an acquisition program. SBA 
is a collaborative environment where all parties involved in the acquisition process work 
together, independent of the physical location, to solve problems and develop processes 
during all phases of acquisition. 

SBA is seen as a tool for the program manager which will reduce risk in cost, 
schedule and performance through (Fallin 1997): 

Continuous evaluation of system development. 

Rapid evaluation of concept design. 

Reduce and delay need for physical prototype. 

Facilitate continuous user participation in development process. 

Efficient development/evaluation of manufacturing plans. 

Reuse of system software and hardware in training simulators. 

Ability to test proposed system at sub-component, component, and system 

level. 

The effectiveness of SBA versus standard acquisition methodology was tested in 
a study performed at the Defense Systems Management College (Brown 1999). An 
acquisition project was developed to design, manufacture, and test prototype vehicles 
meeting a specific set of manufacturing and performance criteria. The students of the 
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Advanced Program Management course (APMC) were divided into groups, one of which 
was a control group. 

Each group was provided with an Operational Requirements Document and 
Statement of Work. Each group received the same materials with the exception of 
software. The control group was provided with standard modeling software used in 
previous APMCs including information relative to one system requirement. This 
software model included only basic design equations. On the other hand, the advanced 
groups were provided an advanced design and simulation tool that not only evaluated 
design for performance, but also relative to cost, weight, and producability. 

Though on average, the additional modeling and simulation (M&S) cost drove up 
the concept development and demonstration costs, from a total life cycle perspective 
simulation based acquisition delivered a more mature, producible design. The author did 
note one drawback to M&S. When a competitive environment was added to the mix, the 
group used M&S to “gain a competitive advantage, not to reduce development cost and 
schedule.” Figures 1-4 show the results of this study. 
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Producibility Index (PI) = (# types of parts) * (# total parts) 



SFR Unit 
Cost($) 


SFR PI 


Final Unit 
Cost($) 


Final PI 


Figure 1. Cost/Producability Comparison 

(Brown 1999) 



M&S Designs Engineering Changes 


Figure 2. Development Comparison 

(Brown 1999) 
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(Brown 1999) 
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Figure 4. Runoff Comparison 

(Brown 1999) 

Simulation Based Research & Development. 

Simulation based Research & Development (SBR&D) is a methodology that 
utilizes a common computer environment for the development of new aerospace concepts 
prior to Milestone B, concept development through design to testing (Air Force Research 
Laboratory 2002). SBR&D therefore supports the DoD’s Integrated Product and Process 
Development (IPPD) management process and its use of multidisciplinary teams to 
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optimize the design, manufacture, business, and supportability. IPPD emphasizes 
concurrent development of product and processes, early and continuous life cycle 
planning, multidisciplinary teamwork, proactive identification and management of risk 
(Department of Defense 1999). 

SBR&D combines a variety of M&S as well as research and technology- 
development tools (engineering-level modeling, design, and analysis tools, mission-and 
campaign-level simulations, cost analysis tools, and database tools) into a common 
computer environment (Zeh and Schumacher 2001). Through the integration of these 
tools, a common synthetic battlespace is developed (Zeh and Schumacher 2001). New 
and current aerospace systems can be inserted into the battlespace where cost and 
performance trade-off studies are accomplished to evaluate the potential benefits of new 
technology capabilities. The three primary goals of SBR&D are (Zeh and Schumacher 
2001 ): 

Guide Air Force Science and Technology (S&T) investment 

Reduce R&D time and cost to develop and mature promising technologies 

Integrate the Warfighter and technologist into the S&T acquisition process. 

Future Reusable Space Vehicles. 

An on-going effort to demonstrate the possibility of creating a quick turnaround 
spacecraft for commercial use has been underway under the title: X-Prize. This 
competition is based on previous competitions of the past that gave monetary prizes to 
the first individual or group that completed a specific event, such as a non-stop solo flight 
across the Atlantic Ocean. Although Lindberg received $25,000 for his feat, the X-Prize 
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is set to award $10,000,000 for the first to fly a vehicle to a height of 62.5 miles above 
the earth with three passengers (or one pilot and the equivalent weight of two passengers) 
and repeat the event within 14 days. The amount of prize money and purpose for the 
competition is in part designed to generate public interest in space flight (CNN 2003). 
Table 1 provides an overview of the various take-off and landing scenarios under 
development for the X-prize competition as well as the number of stages considered. 
Table 2 provides a brief overview for the commercial and public sectors vehicles. 


Table 1. X Prize Contenders 


Take-off Scenario 

Qty 

Landing Scenario 

Qty 

# Stages 

Qty 

Vertical 

8 

Vertical 

1 

Single 

5 

Horizontal 

4 

Horizontal 

11 

Two 

2 

Carrier craft 

8 

Parachute/foil 

6 

Multiple 

1 


. (FAA2000) 


Table 2. Public and Private Sector RSYs 


Take-off Scenario 

Qty 

Landing Scenario 

Qty 

# Stages 

Qty 

Vertical 

8 

Vertical 

1 

Single 

5 

Horizontal 

4 

Horizontal 

11 

Two 

2 

Carrier craft 

8 

Parachute/foil 

6 

Multiple 

1 


(FAA 2000) 
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Much of what is under development is for commercial use whether it is for space 
tourism, payload delivery, or a combination of both. The key problem to successful 
implementation of a commercially viable vehicle is the reduction of cost (Kaplan 2002). 
One of the areas driving up the cost for RSVs is the cost per launch. One way to reduce 
this cost is to enable faster turnaround and increase the number of available launches. 
Even the space shuttle was initially projected to have much shorter turnaround times than 
what currently exists. 

The shuttle was initially planned to have 40 missions per year and have a 
turnaround time of 160 hours(Jenkins 2002). Before the Challenger incident in 1986, the 
shuttle was on target for 16 missions. After Challenger, the target has settled down 
around seven and may decrease once more after Columbia. The current thought on 
launch vehicles is to have turnaround times as short as 48 hours with a 24 hour surge 
capacity with times no longer than 14 days. The Air Force in particular is looking for 
high sortie rates in the neighborhood of 20 per two-week period (Wall 2002). 
Additionally, many of the concepts call for smaller crews to handle the turnaround 
operations especially as compared to the numbers surrounding space shuttle operations. 

Much of the literature on RSVs focused on the information contained in Tables 1 
and 2 above. Additionally, discussions have begun to look at the support and ground 
operations of RSVs. Since no specific type of vehicle has been selected as the “one” 
design to develop, this research will not focus on anyone type nor leave out components 
that may be space shuttle unique. 
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III. Methodology 


Overview 

The overarching design behind this research is a case study lending itself to task 
and contextual analysis. This study will focus on the ground operations of the space 
shuttle as an example of RSV operations. Being inductive in nature, this study will be 
concerned with the construction of a descriptive model. No intent is given at this point to 
compare alternatives only to examine the processes as they currently exist and provide a 
description in the form of a conceptual model. 

This chapter will discuss conceptual models and what is required to present a 
useful model. The need for a model, its purpose, and its characteristics will be discussed. 
Additionally, the methodology chosen for the layout, documentation, and building of the 
conceptual model will be presented followed by a brief examination of how the data will 
be handled. A detailed analysis of the data and how the conceptual model was built will 
be presented in Chapter 4. 

Conceptual modeling 

A conceptual model aids in scope of reuse and in the development of simulation 
models created from the conceptual model. The value of quality conceptual model can 
be seen in the fact that some simulation requirements may be “incomplete, unclear, 
inconsistent, and sometimes wrong” (Pace 2002). A conceptual model provides a great 
benefit for the simulation developer but is still hampered by the experience and 
knowledge of the builder. “Regardless of how it is defined, model conceptualization is 
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considered as much an art as a science” (Rohrer and Banks 1998). The goal is to reduce 
the multitudes of data to useable and manageable pieces that are separate from the noise 
and other distractions. A certain but not easily definable level of abstraction is desired 
from the process. Benjamin et. al. list three levels of abstraction to aid in simulation 
model development: (i) Domain Level, (ii) Model Specification, and (iii) Execution and 
Analysis Level (Benjamin, Delen et al. 2000). 

The Domain Level includes information about processes and their relationships. 
The descriptions may either be process-oriented or object-oriented. The Design Level 
contains information needed to build the simulation model such as input requirements, 
experimental design requirements, and data required to build the simulation. The final 
product from this level is the actual simulation. The last area, Execution and Analysis 
Level, includes the input data and its analysis, the simulation mns, and output from 
experimental runs. The output from this level is the results of the simulation runs and 
conclusions made based on the analysis that follows execution. This may include 


decisions on various trade-offs. The following figure illustrates the three levels. 



Figure 5. Separation of Levels Extends Reuse Scope 

(Benjamin, Delen et al. 2000) 
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As can be seen in this diagram, the Domain Analysis is accomplished before 
specifying a simulation model and gathering detailed information about input data and 
experimental design. This level is just a basic representation of the system to be modeled 
and the major components. Therefore, the focus of this research effort will be on the 
Domain Analysis Level providing ontological and process descriptions as necessary. 

Purpose 

Economic considerations exist emphasizing the importance for reuse of 
simulation components (Pace 2000). Considering the cost of model development, it is 
wise to develop models based on previous work or that have multiple uses. For example, 
NASA’s GEM-FLOW is a generic simulation used to model the launch and in-flight 
operations of various spacecraft to include traditional lift vehicles and the space shuttle. 

A documented conceptual model aids in reuse or use in combination with other 
simulations by allowing others to know the background of the model allowing clearer 
understanding of its limitations and intended purpose. The construction of a conceptual 
or structural model is typically carried out by an analyst as an undocumented thought 
process rather than as an explicitly represented design activity (Benjamin, Delen et al. 
2000). Simulations created in this ad hoc manner, often, do not include documentation of 
the conceptual model if it even existed in the first place. As a result, problems are 
created for the future use of the simulation since the final executable simulation is the 
only documentation. 

Description 

Conceptual models tell the customer what the system will do. A conceptual 
model translates modeling requirements into a detailed design framework (Pace 2000) 
and is the collection of information that describes a simulation developer’s concept about 
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the simulation and its pieces (Pace 2000). It is the primary mechanism for clear and 
comprehensive communication among simulation developer and implementation 
personnel (Pace 2000). There are several questions that can be answered by a conceptual 
model (adapted from (Pace 2000). 

What objects will be in the system? 

What will happen to the objects in the system? 

What will the system look like to simulation developers? 

What choices will be offered to simulation developers? 

What is the timing of events? 

What will the output look like? 

A conceptual model is the framework upon which a simulation will be built. 

When more than one simulation is interconnected into a system it is called a Federation 
of Models and Simulations and the simulation is referred to a Federate (Department of 
Defense 2003). Conceptual models have been used for the development of databases, 
software programs, and clarifying and describing processes leading to the development of 
a simulation model. However, a conceptual model can itself be an end product used 
primarily for the purpose of description. 

The characteristics of a good conceptual design include the use of customer 
language not jargon, system function descriptions, implementation independence, and 
linked to requirements linkage. A conceptual design is different from a technical design 
in that the latter tells programmers what the system will do and includes major hardware 
components and their function, hierarchy and function of software components, data 
structures, and data flow. 
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A conceptual model should contain three components: simulation context, 
mission space, and simulation space (Defense Modeling and Simulation Office 2000; 
Pace 2000). The simulation context contains the laws of physics and principles of 
engineering included in a physical model. Mission space refers to simulation elements: 
entities, assumptions, algorithms, characteristics, relationships, and data. The simulation 
space contains additional information “needed to explain how the simulation will satisfy 
its objectives” (Pace 2000). The mission and simulation space are both part of the 
simulation concept. These components can be seen in Figure 6 below: 



Figure 6. Conceptual Model Components 

(Defense Modeling and Simulation Office 2000; Pace 2000) 

Several design steps for conceptual models have been put forth by various 
authors. Benjamin et al suggest the following steps: (i) Determine the specific goals of 
the simulation study: what is the objective? (ii) Determine the object roles, boundary and 
level of detail selecting the part to be studied, level of abstraction, and identify model 
objects and roles (Defense Modeling and Simulation Office 2000; Pace 2000). 

Pace suggests the following design steps (Defense Modeling and Simulation 
Office 2000; Pace 2000). First, the model builder needs to collect authoritative info 
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about the context. This involves creating authoritative descriptions of entities, processes, 

and situations. It “should address everything needed to fully describe the domain of the 

simulation” (Defense Modeling and Simulation Office 2000). When less is known about 

the context, the effort becomes more difficult. The next step is to identify entities and 

processes referred to as decomposition of the mission space. This step is where decisions 

are made about the level of detail and drill-down and can help the model stay with the 

established scope. The following lists several principles of decomposition: 

There should be a specific simulation element (parameter, entity, etc.) for 
every item (parameter, entity, etc.) specified for representation in the 
simulation by simulation requirements. 

There should be a specific simulation element (parameter, entity, etc.) for 
every item (entity, task, parameter, state, etc.) of potential assessment 
interest related to the purpose of the simulation. 

There should be “real world” counterparts (objects, parameters for which 
data exist or could exist, etc.) for every simulation element as far as 
possible. The potential impact of data, and metadata structures, on 
simulation elements and the simulation conceptual model should not be 
underestimated. 

Wherever possible, the simulation elements should correspond to 
“standard” and widely accepted decomposition paradigms to facilitate 
acceptance of the conceptual model and effective interaction with other 
simulation endeavors (including reuse of algorithms and other simulation 
components). 

Simulation elements required for computational considerations (e.g., an 
approximation used as a surrogate for a more desirable parameter that is 
not computationally viable) that fail to meet any of the previously stated 
criteria should be used only when absolutely essential. 

There should not be extraneous simulation elements. Elements neither 
directly related to specific items in the simulation requirements nor 
directly implied by potential assessment issues and elements without a 
specific counterpart in the real world or in standard decomposition 
paradigms should not be included in the simulation conceptual model. 

Every extraneous simulation element is an unnecessary source of potential 
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simulation problems (Defense Modeling and Simulation Office 2000; Pace 

2000 ). 


The third step involves developing simulation elements necessary for each entity or 
process detailed in the previous step. “Simulation elements determine functional and 
behavioral capabilities of the simulation” (Defense Modeling and Simulation Office 
2000). The last step is to define interactions and relations among simulation elements 
ensuring all the relationships among simulation elements are addressed. Additionally, all 
constraints and boundaries set by the domain should be imposed and expressed within the 
requirements (Defense Modeling and Simulation Office 2000; Pace 2000). 

When laying out the model, it is best to keep it structured and modular allowing 
for more flexibility and more rapid development (Rohrer and Banks 1998). Although the 
process of abstracting from reality can be difficult, it is best to have some structured 
approach guiding the process. 

Documentation 

The documentation should provide a “coherent set of information that fully and 
correctly describes the conceptual model so that its capabilities, limitations, and 
characteristics can be readily understood by simulation development personnel; 
verification, validation, and accreditation personnel; and by subject matter experts 
involved in simulation assessments” (Pace 2000). 

When completing the project, there are several items to include in final product 
which include the following: 

A write-up about the various sub-systems in the system 

A set of conceptual drawings of the main individual components 
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A technical description for the complete system, explaining the function of the 
system 

Detailed costing and commercial aspects for development of the complete system 

Recommendations 

Visualization 

Knowing what a conceptual model is and what to include still leaves one question 
unanswered: What graphical/visualization methods can be used for displaying conceptual 
models? A simplistic method would be the use of flowcharts describing the entities, 
processes, and flows through the overall process, but this method might not capture the 
full dynamics of the system. Flowcharts would be best suited as an initial step in 
development for gathering ideas and laying out a general flow—such as an activity 
diagram (Cochran and Wheaton 2002). Still another methodology exists that not only 
provides for the visualization of the model, but satisfies the requirements discussed in this 
chapter for the development of a quality conceptual model. 

Integrated Definition (IDEF) Model 

The methodology that satisfies all the requirements for conceptual model 
development is IDEF3. IDEF began as an Air Force program for Integrated Computer- 
Aided Manufacturing (ICAM) where the first ICAM Definition was created and later 
recast as it currently stands with several versions now available (Mayer, Menzel et al. 
1995). IDEF was initially created to be a set of methodologies that would represent 
manufacturing systems. The first set of IDEF methodologies, IDEFO, IDEF1, IDEF2, 
and IDEF3, were developed for functional, data, dynamic analysis, and process modeling, 
respectively (Kusiak and Zakarian 1996). 
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IDEFO is used to model flows with an emphasis on decisions and actions. IDEF 0 
allows for process descriptions with the inclusion of control mechanisms that affect and 
direct the flow of information or objects. IDEF1 was designed to be used with software 
and communication model development and analysis. IDEF2 provides for the description 
of dynamic systems but leaves out guidance on graphical representations allowing the 
user to develop models using language-specific figures. IDEF3 provides for process 
modeling in addition to object-oriented views. Several other methods are under 
development or being proposed but are not geared towards process modeling which is 
important to this research effort. 

Of the IDEF methods listed above, IDEFO and IDEF3 provide the most 
possibilities; however, IDEF3 provides the most functionality and is better suited towards 
the development of a conceptual model of physical processes. The Table 3 summarizes 
some key attributes of a conceptual model and how it is addressed by a IDEF3 model 
detailing how an IDEF3 model meets the criteria of a conceptual model. 

Although IDEF3 satisfies the ability to develop ontological in addition to process 
descriptions, another methodology, IDEF5, has been developed to build ontological 
descriptions. The difference is that IDEF3 provides a means for describing processes to 
include precedence, object flow, and relational links (Kusiak and Zakarian 1996) and for 
the description of entity state changes detailing the processes involved. Being a more 
capable methodology, IDEF3 has been chosen for this research effort. The following 
table will compare the IDEF3 methodology to the attributes of a conceptual model. The 
chapter will continue with a description of IDEF3 components and a brief explanation of 
the development process. 
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Table 3. Comparison of Model Attributes 


Attribute 

Model 

Conceptual 1 1DEF3 

1 Domain Analysis 1 


Ontology Descriptions 
Process Descriptions 

Satisfies Domain Level 
analysis which is 
comprised of 
ontological and process 
descriptions. 

| Validation (appropriateness) | 

Completeness 

1/1 entity to process ratio 
Simulation space 
components addressed 
Satisfies specifications 
for simulation 

Requires one unit of 
behavior (UOB) or 
object symbol for every 
activity/process or 
object, respectively 
Allows for more data in 
the form of notes, 
elaborations, file 
attachments, and 
description addressing 
simulation space and 
specifications 

Consistency 

All perspectives are 
compatible 

Allows for both object- 
oriented and process- 
oriented views utilizing 
the same components 

Coherence 

All elements have a 
function and can be 
activated 

All elements must have 
a real world counterpart 

1 Characteristics 1 


Functional descriptions 
Generalized language; no 
jargon 

Functional descriptions 
Terminology set by the 
modeler 

| Three components | 


Simulation context 
(physical constraints) 
Mission space (entities, 
assumptions, 
relationships, etc.) 
Simulation space 
(additional information 
needed to identify how 
the simulation will 
satisfy objectives) 

Physical constraints set 
by links 

UOBs and other 
schematic symbols 
cover all entities, etc.; 
notes, elaborations, etc. 
cover assumptions 
Elaborations, notes, 
descriptions, and file 
attachments allow for 
addition of more data 

1 Documentation 1 


Subsystem write-up 
Conceptual drawings 
Technical system 
description 

Decompositions allow 
for subsystem inclusion 
in a hierarchical format 
1DEF3 schematics 
Elaborations, notes, 
descriptions, and file 
attachments 

1 Viewpoints 1 


Event-oriented 

Object-oriented 

Event-oriented 

Object-oriented 
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IDEF3 

IDEF3 was created to capture descriptions of sequences of activities with the 
primary goal of providing a structured method by which operational and system 
knowledge can be expressed (Mayer, Menzel et al. 1995). An IDEF3 model serves to 
detail the simulation context and simulation concept. To achieve this goal, an IDEF3 
model must support the items the following list (adapted from (Mayer, Menzel et al. 
1995). 

Scenarios of organizational activities. 

Roles of entity types in the organizational activities. 

Entity scenarios or entity interaction with the system at the entity-function level. 

System response to entity functions. 

Entity classes and delineation of entity classes. 

Declaration of timing, sequencing, and resource constraints. 

Entity interface objects (e.g., tools, test equipment, and facilities) 

Several software packages have been produced that produce IDEF products. 

Meta Software’s Workflow Modeler produces IDEFO diagrams. IDEFine Ltd has 
developed software to work with IDEFO and IDEFlx. However, neither of these would 
be useful in this endeavor since they do not work with IDEF3. For this work, three 
software packages were examined. Knowledge Based Systems, Inc.’s (KBSI) ProSim, 
Computer Associates International’s AllFusion: Process Modeler, and Popkin Software’s 
System Architect. All three produce IDEF3 products with the latter two working with 
IDEFO as well. Of the three, ProSim was the most user-friendly providing a graphical 
interface and capability for exporting to MS Visio, MS Project, and HTML coding for 
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use in any web browser. KBSI is the prime contractor for the Armstrong Laboratory, 

Human Resources Directorate, Logistics Research Division, Wright-Patterson AFB, OH 

for the development of IDEF software, ProSim. According to KBSI, the following are 

uses of the IDEF3 methodology (Mayer, Menzel et al. 1995). 

Record the raw data resulting from fact-finding interviews in systems analysis 
activities. 

Determine the impact of an organization's information resource on the major 
operation scenarios of an enterprise. 

Document the decision procedures affecting the states and life-cycle of critical 
shared data, particularly manufacturing, engineering, and maintenance product 
definition data. 

Manage data configuration and change control policy definition. 

Make system design and design trade-off analysis. 

Provide simulation model generation. 

IDEF 3 Models have been used for the development of conceptual models 
(Cochran and Wheaton 2002), reliability evaluation (Kusiak and Zakarian 1996), and 
simulation development (Benjamin, Delen et al. 2000) as well as business process 
reengineering but is not limited to these efforts. The IDEF3 methodology does not 
capture all aspects of the system though it can be used in conjunction with other methods 
to provide a very detailed description. Although other methods can be added, it is 
essential to stay within the scope of this research and focus on the description of the 
processes and development of the conceptual model keeping efforts within the scope of 
Domain Analysis. 

Benefits ofIDEF3 Methodology 

Some benefits of the IDEF3 methodology are realized through its ability to 
identify obscure process links, highlight redundant and/or non-value-added activities, and 
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speed the design of new processes. Some of the benefits realized by the use of the IDEF3 
methodology are listed below. 

Capture and distribute detailed manufacturing process knowledge (e.g., Hubble 
telescope mirror fabrication process) among geographically dispersed units. 

Determine the impact of an organization’s information resource on the major 
operating scenarios of an enterprise. 

Provide an implementation-independent specification for human system 
interaction. 

Define data configuration management and change control policy. 

Document the decision procedures affecting the states and life cycle of critical 
shared data. 

Speed the development of high quality IDEF function models. 

Speed the development and validation of simulation models. 

Develop real-time control software by providing a mechanism to clearly define 
facts, decision points, and job classifications. 

Define the behavior of workflow management systems and applications. 

Prescribe the process by which change within an organization will be achieved. 

IDEF3 is useful in both capturing the system description and in model 

development (Belhe and Kusiak 1995). A well developed description and conceptual 

model will be very useful in the reuse of model components. Additionally, IDEF3 allows 

for the capture of alternative views or descriptions enhancing the understanding of the 

system and the usefulness of the model. Mayer et. al. explained, 

“When compared to model building, description capture is attractive as a 
strategy for knowledge acquisition for several reasons. First, practitioners 
generally require less training to produce descriptions, rather than models, 
of their domains. Second, a model description of a given situation can 
easily be reused for a variety of purposes, including model building (e.g., 
function models, simulation models). IDEF3 is a description organizing 


33 



and capture method that directly addresses these needs” (Mayer, Menzel et 
al. 1995). 

IDEF3 Components/Elements 

IDEF3 methodology has four major components. Boxes or UOBs are used for 
processes, arrows or links to represent precedence or relationship, junctions are used to 
add logic to the diagram, and circles are used when focusing on ontological descriptions 
to represent object states. Additional symbols include referents and notes. The IDEF3 
schematic serves to detail the simulation concept. The mission space contains the process 
elements and is comprised mostly of the schematics. The simulation space and the 
simulation context are addressed by elaborations, notes, and referents that will be 
discussed later. The following figures provide an example of the two types of diagrams 
developed through the IDEF3 methodology. 

Figure 7 provides a simple view of the process-oriented perspective. Within this 
diagram are several processes linked together showing the order of precedence. 

Although this diagram is simple in nature, it contains the all the key components of a 
IDEF3 schematic. Additional information and documentation can be added as necessary 
and will be discussed later in this chapter. 



Figure 7. Sample IDEF3 Process Diagram 

(Mayer, Menzel et al. 1995) 
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Figure 8 provides an example of how IDEF3 can be used to produce an object- 


oriented diagram. In this view, an object and its current physical state are represented by 


the circles with the processes acting upon the object coming in perpendicularly. This 


viewpoint can be used to follow and object through various processes detailing the 


current status of that object. 



Figure 8. Sample IDEF3 State Diagram 

(Mayer, Menzel et al. 1995) 

Both the previous examples utilized the most common symbols; however, there 
are more symbols that help to make the IDEF3 methodology more useful. The basic 
elements used to develop an IDEF3 description are contained in Figure 9. 

UOBs are used to describe what happens in general within the system and not 
necessarily what happened at a particular time. It represents an activity that happens 
repeatedly over time. In the case of a process, the description represents types of 
situations that can occur in the system and the logical and temporal constraints that bind 
them together (Mayer, Menzel et al. 1995). 
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Figure 9. IDEF3 Methodology Schematic Symbols 

(Mayer, Menzel et al. 1995) 

Links are used to connect symbols creating the dynamic process representation. 
Primarily used to denote relationships, links generally include express temporal, logical, 
causal, natural, and conventional. The most common use is for temporal precedence 
represented by a solid black line with an arrow point on one end. Additionally, there are 
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four types of constrained precedence links. They are represented by a directional triangle 
on the line, a double triangle allowing for both directions, and a square representing a 
general constraint. Lastly, dashed links are not predefined and are therefore usually user 
defined (Mayer, Menzel et al. 1995). 

Junctions provide for the ability of expressing the logic of process branching 
while simplifying temporal sequencing relationships between processes. There are four 
types of junctions. 

Points at which a process diverges into multiple parallel subprocesses; 

Points at which a process diverges into multiple (possibly nonexclusive) 
alternative subprocesses; 

Points at which multiple parallel subprocesses converge into a single “thread;” 
and 

Points at which multiple alternative subprocesses in the process converge into a 
single thread. 

The four types of junctions represent the four sorts of branch points. The first two 
represent the fan-out type while the remaining two are for fan-in type branches. 
Conjunctive branches are used with multiple parallel processes while disjunctive 
branches are used with multiple alternative subprocesses. Conjunctive branches are 
represented by the symbol “&.” Disjunctive branches can be either inclusive or exclusive 
represented by “OR” and “XOR” respectively (Mayer, Menzel et al. 1995). 
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Table 4. IDEF3 Junction Types 


Junction Type 

Fogic 

Synchronization Type 

Description 

Fan-in 

AND 

Asynchronous 

All preceding processes must be 
completed before preceding 
forward. 

OR 

One or more of the preceding 
processes will complete. 

AND 

Synchronous 

All preceding processes will 
complete simultaneously. 

OR 

One or more of the preceding 
processes will complete 
simultaneously. 

XOR 


Exactly one of the preceding 
processes will complete. 

Fan-out 

AND 

Asynchronous 

All following process must 
start. 

OR 

One or more of the following 
processes will start. 

AND 

Synchronous 

All following processes will 
start. 

OR 

One or more of the following 
processes will start 
simultaneously. 

XOR 


Exactly one of the following 
processes will start. 


(adapted from (Vernadat 1996) 
To further enhance the ability of the IDEF3 methodology for process description, 
decompositions are added to give greater detail and insight into the system. 
Decompositions are used to generate a hierarchical view of the process showing the 
subprocesses contained within a single UOB. By enabling this “drill-down” or exploded 
viewpoint capability, it is possible to view the process at various levels of detail 
depending on the information desired. 
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Additionally, various types of information can be attached to a process. This 
information includes elaborations, properties, simulation info, attachments, 
decompositions, notes, and sources. As they appear in ProSim 7.0 from KBSI, an 
Elaboration block is used to provide information about objects, facts, and constraints. 

The types of properties added are integer, real, string, Boolean, or user defined. With 
each property is stored its value, a description, notes, and source information. If needed, 
simulation data can be entered and stored. Attachments can be inserted to provide 
additional information including data files, pictures, or text. A list of decompositions and 
access to information regarding each is accessible at this point; each decomposition can 
contain any of the symbols available representing some subsystem within the whole 
process. Lastly, notes may be added to give further explanation and sources of 
information may be recorded to allow others to return to the source for further 
explanation. 

Like the Elaboration block in a process diagram, there is an additional block in 

the object-centered view: Referent. Referents enhance understanding and simplify the 

construction of descriptions. Referents are generally used to accomplish three functions. 

Refer to a previously defined UOB without duplication of its definition to indicate 
that another instance of a previously defined UOB occurs at a specific point in the 
process (without loopback). 

Transfer control or indicate a loopback in the processing. 

Lorm references or links between the process schematics and object schematics. 
There are two types of referents: Call-and-Continue Referent and Call-and-Wait 
Referent. The Call-and-Continue type is the most common used referent and represents a 
situation where the referenced element needs to be initiated and then the processes can 
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continue. The Call-and-Wait type represents the situation where situation where the 


process continues after the referenced element has completed its processing. The 
following table contains the various referent symbol structures. 


Table 5: Referent Symbol Structure 


Relcrcnt Type 

Referenced Element 

Label 

Locator 

UOB 

UOB Label 

UOB# 

SCENARIO 

Scenario Label 

Scenario # 

TS 

Transition Schematic 

Label 

Transition Schematic # 

GO-TO (used only in 
process schematics) 

UOB Label 

UOB#/Scenario # or 
Decomposition # in which the 
ID occurs 


Scenario Label 

Scenario # 


Junction Type (i.e., &. 0, 
orXOR) 

Junction #/Scenario # or 
Decomposition # in which the 
ID occurs 


(Mayer, Menzel et al. 1995) 


IDEF3 Development 

Cochran and Wheaton suggest that development of a IDEF3 model begin with a 

simple context model, be supplemented with an activity model containing discrete 

elements, and then add a hierarchical breakdown view of activities (Cochran and 

Wheaton 2002). When developing IDEF3 descriptions, the following evolutionary cycle 

can be used to capture the knowledge about activities and processes. 

Collect: Acquire observations and written descriptions of both process 
instantiations and generalizations across process instantiations. 

Classify: Individuate situation types, objects, object types, object states, and 
relations. 

Organize: Assemble the data that has been collected and classified using IDEF3 
structures 
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Validate: Ensure that the statements made in IDEF3 are grammatically correct 
and that they corroborate with the collected descriptions of the actual or idealized 
situation. 

Refine: Make adjustments to the existing structures to incorporate newly 
discovered information, to simplify the presentation, or to highlight important 
elements interest (Mayer, Menzel et al. 1995). 

Using these steps and a combination of the conceptual model building steps suggested by 

Benjamin et al and Pace should enable the model developer to gain a greater 

understanding of the process while providing the appropriate amount of detail needed for 

reuse and conversion to a simulation model. 

Conclusion 

For this research effort, data concerning the processes surrounding space shuttle 
ground turnaround operations will be collected and used to generate UOBs with 
elaborations and other descriptions being generated as needed. The data will come from 
work breakdown structures, process diagrams, tables and spreadsheets, and from subject 
matter experts. The data will be organized as needed and then organized into an IDEF3 
structure that will paint the picture of operations at KSC. Once the IDEF3 model has 
been generated, the researchers will validate the model based on the data collected and 
descriptions generated ensuring statements made are grammatically correct and that they 
express the proper view of the actual system. If any new information is uncovered during 
this process, it will be added and adjustments will be made while the model is kept as 
simple as needed and contains enough detail to be complete. 

Five steps will be used to conduct the data analysis. The first is to organize the 
data and facts. This is a general collection and organization. The next step is to identify 


41 



categories for organizing data and facts into meaningful groups. The third step is to give 
special attention to specific items requiring examination for relevance. Next, patterns and 
groups are determined based on a logical structure for the model. The last step is to 
proceed with model development (Leedy and Ormrod 2000). 

To simplify the model development process and to enable the completion of the 
above steps, a simple method has been chosen to reduce the data to a more manageable 
and meaningful level. Data relating to procedures scheduled and performed on the space 
shuttle on a regular basis will be included. Data such as trouble shooting unexpected 
errors or malfunctions and modifications will be removed from the data set. Any 
subsequent data generated as a result of these procedures will be removed as well. 

Chapter 4 will detail this process and how it was conducted with the actual data as well as 
present the various components of the model. 

To build the model, the system will need to be divided into usable and meaningful 
groups. Several possibilities exist for these groupings. First, all the processes within 
each structure could be grouped and modeled. Another possible method would be to 
group by similar structure or function—component based. In this model, the grouping 
would be by system or sub-system regardless of facility. Additionally, the groupings 
could be based on process ID or procedure number. This would allow similar activities 
to be grouped. However, each of these on their own would not provide a proper 
description or dividing point for data analysis. The best choice is a combination of the 
three. In general, activities will be grouped by system or sub-system with procedure 
numbers and process IDs being used to help make this division. In some cases, the 
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procedures for a single system occur in multiple facilities; therefore, larger more complex 
procedures will be first divided by system and then subdivided by facility. 

By focusing on systems rather than some other grouping method, the focus is 
placed on the entities where trade-offs will occur. Also, the model will be more 
adaptable and attuned towards reuse. As changes are needed for each sub component of 
the model, only that section will require action. Additionally, components of the model 
will be ready for inclusion or exclusion as required in order for the model to evaluate 
various scenarios. 

In the end, the IDEF3 model will provide the necessary data for the simulation 
developers to understand the processes involved in space shuttle turnaround enabling 
them to analyze the system further for the development of a generalized simulation. 

Based on this initial understanding, the simulation developer will be able to prepare for 
various alternative choices and analyses needed to aid in system development. One of 
the main advantages to be gained from this effort is an understanding of process flow, 
precedence, and relationships in the form of IDEF3 schematics with drill down capability 
on processes that require greater detail. 
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IV. Analysis and Results 


Overview 

This chapter will answer Investigative Question # 4 utilizing the methodology 
discussed in Chapter 3 (Question # 3). This chapter will begin with the scope and 
limitations of this analysis will be discussed followed by the threats to validity. The 
assumptions made in laying out the conceptual model will be discussed in addition to the 
analysis of the data followed by the results. The results will be in the form of a more 
detailed discussion of the operations at KSC as laid out in the model along with 
appropriate diagrams with the full model being included in Appendix B. 

Scope and limitations 

The scope of this project was to stay within the Domain Analysis function and 
was therefore limited to the development of a conceptual model. The analysis and 
subsequent model development will be limited by the data available from KSC. The 
model developed will be a baseline conceptual model; no analysis of the processes will 
be made. 

Threats to validity 

Researcher bias may influence data examined either by preconceived ideas on 
process flow or by leaving out data that was felt to be unimportant. When collecting data 
from an individual, the interviewee may influence the analysis by answering questions 
based on their own opinion of the data and/or by selectively or inadvertently supplying or 
not supplying data. The data collected is primarily dependent upon the resources 
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available at KSC. If the data is not available or lacking, the model will either be 
inaccurate or insufficient in the area of concern. Additionally, the sponsor may influence 
the direction of research effort based upon their own preconceived ideas. 

Assumptions 

The selected assumptions may influence data examined, responses from the interviewee, 
interpretation of observed operations, and data selection. Selection of model components 
may affect the usefulness and generalizability of the model. The following assumptions 
were used when analyzing the data and building the model: 

Unscheduled maintenance and troubleshooting is not relevant to the development 
of this baseline model. This data represents activities not performed on a regular 
basis. 

Data analysis 

The basis for the data analysis is a contextual analysis. The data was examined 
for activities that represented the general flow of operations at KSC for the turnaround of 
the space shuttle and its components in preparation for the next launch. These operations 
included those for processing the orbiter and its major subsystems, the solid rocket 
boosters (SRB), the external tank (ET), and the mobile launch pad (MLP). The 
processing of the orbiter comprises the greatest amount of time and effort. Because of its 
size, this activity required decomposition for greater analysis and understanding. 

The breakdown of orbiter processing was driven by its size and complexity and 
one additional factor: reusability. In order for this model to be useful in examining other 
vehicles and conducting trade-off analysis when coded as a simulation, the data was 
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divided into groups allowing for the creation of modules. These modules could then be 
included or excluded as necessary for varying vehicle types. For example, a new type of 
TPS might be developed that does not require the use of tiles. Therefore, the tile 
manufacturing module would no longer be necessary. 

To analyze the data, a three step process was used modeled after the first four of 
Leedy’s five steps in Chapter 3. The first step was to organize and collect the data. Next, 
areas requiring special attention for examination need to be identified examining the data 
for relevance. The third step is to group the data into categories looking for patterns and 
logical structure. 

Organize and collect the data 

The data used in this analysis came from several sources and in several different 
formats. The formats of the data were as follows: 

Spreadsheets 
Tables 
Flowcharts 
Gantt Charts 
Presentations 
Pictures 
Diagrams 
Reports (textual) 

This data provided names of various processes and subprocesses in addition to start and 
stop times. It provided descriptions of flows and sample high level diagrams that were in 
some cases the only source of data for analysis. Also, there were pictures and 
descriptions of facilities. Some sources provided detailed descriptions of various systems 
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and components. Other sources provided high level scheduling data while others 
provided detailed processing data down to the individual task performed. 

Some of the data was focused on Space Transportation System (STS)-81, which is 
considered the baseline minimum scheduled time. Other data sources were from 
combined mission data for post-Challenger missions. The pre-challenger missions were 
considered to be too dissimilar to those following that they were not included. 
Additionally, STS-114 was included at a higher level of detail as a comparison to STS-81 
along with a generalized schedule. 

Identify categories 

What was discovered is that the same general procedures are completed on each 
mission especially those concerning major systems that are of greatest interest. The 
differing data sources provided varying levels of detail from system to system, but when 
combined provided a clearer picture of procedures throughout the whole ground 
turnaround process. Some influence in this matter came from the sponsor’s focus on TPS 
and propulsion systems. 

The area containing the greatest amount of information was the data sources 
concerning the space shuttle main engines (SSME) and the thermal protection system 
(TPS). These two areas are considered the most important for trade-off analysis and have 
been the focus by both NASA and AFRL/VA. Therefore, the initial emphasis was placed 
on these two systems. Other areas were added as data and time permitted with the intent 
of producing the most comprehensive and complete model possible. 

Group the data 

When examining the data, some sources contained extraneous data needing to be 
filtered out to enable a clearer view of the pertinent data. Some of this data concerned 
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non-maintenance activities and were thus not part of the ground operations; some of the 
data was for operations not performed at KSC; and some concerned unscheduled 
maintenance. Additionally, data concerning modifications and upgrades was not 
included in the model. Any data not scheduled or out of the scope of this research was 
removed from the data set and was not considered in this effort. 

Results: Baseline Conceptual Model 

This section will detail the model as developed beginning with the highest level 
and then presenting each decomposition as necessary to clarify the major components of 
the model. Diagrams from the model will be provided as needed while the whole model 
will be available in Appendix B. 

Overarching 

KSC is responsible for launch operations, landing and recovery procedures, and 
ground turnaround for all equatorial orbits. The ground operations at KSC required to 
turnaround the space shuttle being considered are those from launch to launch but not 
including any mission elements. Launch to launch is considered since some of the 
activities considered begin soon after launch—such as SRB retrieval and MLP 
refurbishment, which begin soon after launch. The major activities take place in several 
different facilities located relatively close to each other with the exception of hazardous 
functions being geographically separate. 

The shuttle industrial complex is composed of many buildings utilized in the 
processing of STS components and systems. Some of the facilities are left over from the 
APOLLO space program and some are new structures built specifically for the shuttle 
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program. Additionally, there are facilities in other areas that support the shuttle mission. 
The facilities considered in this effort are the hypergol maintenance and checkout facility 
(HMF), TPS facility, OPF, vehicle assembly building (VAB), MLP refurbishment 
facility, and launch pad. Within some of these facilities may exist multiple structures and 
bays. The details of these facilities will be discussed along with the operations are 
conducted within that facility. Figure 10 provides the schematic for this schematic. 



Figure 10. Overarching Diagram 
1.0 Landing Prep/Recovery Operations 

This module discusses the operations conducted beginning when the landing is in 
preparation and when the orbiter actually touches down. Prior to landing, vehicles, 
equipment, and personnel are made ready. Additionally, the weather is checked to ensure 
all things are go for a landing at KSC. NASA does have three other locations for landing 
if the weather is not good at KSC and time is short (not modeled in this effort). Once the 
decision is made to land at KSC, vehicles, equipment, and personnel take their positions 
and converge on the orbiter once it comes to a stop. Before the crew may exit the orbiter 
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and maintenance personnel may approach, a toxic vapor test is conducted. Once the area 
is declared safe, the crew exits, time critical payloads are removed, some systems are 
purged, a walk down inspection of the TPS is made, and the tires are inspected. Figure 
11 provides the schematic for this decomposition. 



Figure 11. Landing Prep/Recovery Operations 


2.0 Post Flight Ground Handling 

This module concerns the operations necessary to transport the orbiter from the 
runway to the OPF. Once on the ground the orbiter has no means of propelling itself; the 
orbiter free falls and then glides to a landing having no powered flight on re-entry. When 
ready, the orbiter is then towed to the OPF for processing. 



Figure 12. Post Flight Ground Handling 
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3.0 Orbiter Processing 

This is the single largest module containing several decompositions with some 
having multiple decompositions of their own. The dividing of data and creation of 
modules for the model was in part driven by divisions present in the data form KSC. 
KSC tended to look at systems and divide the actions on those systems by facility. 
Therefore, this research effort took advantage of the inherent divisions within the data. 

Before diving into the model, a brief overview of the major facilities involved 
with this section is required. A description of the OPF and the HMF will be provided 
followed by a description of the orbiter processing decomposition. Figure 12 provides 
the schematic for this level of decomposition. 

OPF 

Within the OPF are three bays. Since there are three orbiters in the inventory, 
physical capacity is not a problem. Operations considered for the OPF are those that 
begin at OPF roll-in and end at rollout but do not include concurrent operations in other 
facilities. For example, the SSME are removed and sent to the orbiter main engine 
maintenance facility (OMEMF) and are either returned or replaced with already 
refurbished engines. The operations in the OMEMF will be dealt with separately. The 
main activities in the OPF considered for modeling by NASA have been broken down to 
three areas. 

External surface preparation to include the TPS. 

Payload, midbody, and crew compartment work. 

Propulsion system especially around the main engine compartment. 

Not mentioned above are many other important tasks that must be integrated 
into the flow such as: safing the forward reaction control system (FRCS), 
changing the tires; polishing the windows; trouble-shooting the previous 
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mission’s in-flight problems and a host of minor problems that occur during 
the course of any OPF flow; and performing approved modifications (Cates 
2003) 

For the OPF, the orbiter is rolled in, jacked up, and remains in place until it is time to 
lower it down and send it to the VAB. Personnel, tools, and test equipment come to the 
orbiter. Some components are removed and maintenance is performed in other locations. 
When servicing is complete, those components are returned and reinstalled. OPF 
processing takes approximately 80 days to complete. 

HMF 

The HMF is one facility where components may be removed and taken to for 
further maintenance and is located approximately 8 miles from the main complex due to 
hazardous materials (hypergolic fuels) handling. This facility is used to process reaction 
control system (RCS) components, orbital maneuvering system (OMS) pods, and 
auxiliary power units (APU). The HMF consists of three buildings which contain test 
cells for the OMS pods and FRCS, storage for the OMS pods and FRCS, and 
maintenance/servicing centers for the APUs. Building M7-961 contains two test cells 
each one for either the left or the right OMS pod. Building M7-1212 contains two bays 
as well. One bay is for FRCS processing and the other is not functional. The latter bay is 
used for storing one OMS pod or one FRCS. 
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Figure 13. Orbiter Processing 



















3.1 ECS, Crew Module, GNC, Life Support, & Comm 

Development of the ECS, Crew, GNC, Life support & Comm module was based 
upon data documented in the OPF_dB_STS81_LbrClrs excel spreadsheet. The initial 
239 lines of data were initially reduced by approximately thirty percent by removing lines 
of data designated as “unplanned troubleshooting and repair”. The remaining 167 lines 
of data were broken down by five “design disciples” for model development including: 

Command, Control, & Health Management 

Guidance, Navigation and Control (GNC) 

Cockpit & Crew Panel 

Environmental Control & Life Support System (ECLSS) 

Communications (COMM) 

Though start and finish data was provided, it was unclear if this resulted from a physical 
or resource constraint. Therefore, unless obvious precedence was observed (i.e., removal 
before installation), tasks are modeled in parallel. 

Command, Control, & Health Management subsystem includes the computer 
processors (DPS) and multifunction electronic display (MEDS) as well as orbiter 
instrumentation. The GNC system utilizes the four of the DPS computers during critical 
flight control phases of the mission. Recycling tasks within these modules are non- 
hazardous in nature and include checkouts of the DPS complex, MEDS, flight recorder, 
master timing unit, and other instrumentation systems. 

Cockpit & Crew Panel and the ECLSS include inspection and maintenance of the 
cabin air conditioning/recirculation and flight-crew systems. The ECLSS system is 
critical to the atmospheric conditions within the crew station. Of primary importance is 
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the control of temperature and pressures required not only for survival of the crew, but 
also critical electronics. Tasks within this module are non-hazardous and the inspection 
and maintenance of the cabin air recirculation system require orbiter power down 
conditions. 

The communication system includes the microwave scanning beam landing 
system, the KU band antenna (located in the payload bay), the tactical air command & 
navigation system, GPS antenna, close circuit television, among other systems. 
Inspection and testing tasks within this module are non-hazardous. 
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Figure 14. ECS, Crew Module, GNC, Life Support, & Comm 

3.2 Ground Systems and Facilities 

Within this module, the orbiter is connected to various ground systems providing 
power, cooling, and other services shutdown when the internal systems were deactivated. 
In addition, the orbiter is jacked up off its landing gear and suspend. Next, ground access 
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systems are put into place allowing access to all parts of the orbiter from top to bottom. 
These systems can be moved and adjusted to gain access to various parts of the orbiter 


without obstructing other procedures. 



Figure 14. Ground Systems and Facilities 


3.3 Payload Ops 

Though data was available in the OPF_dB_STS81_LbrClrs excel spreadsheet, it 
was unclear which data was generic payload bay preparations versus specific mission 
payload tasks. As a result, development of the Payload Accommodations module was 
based upon data documented in the STS-81/OV-104 OPF Assembly Summary Gantt 
charts. Though start and finish data was provided, it was unclear if this resulted from a 
physical or resource constraints. Therefore, unless obvious precedence is observed or 
milestones provided, tasks were modeled in parallel. 
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The payload bay area contains four critical systems; orbital docking system, 
radiator system, and fuels cells, and the crew equipment interface system. The 
conceptual model initiates parallel functional/mechanical testing verification, and 
closeout of these systems. Following closeout of the individual systems, the payload bay 
undergoes a final cleaning, closeout and the function of hatch is verified. 
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Figure 15. Payload Accommodations 








3.4 Power Management 

Development of the Power Management module was based upon data documented in the 
OPF_dB_STS81_LbrClrs excel spreadsheet. The initial 324 lines of data were initially 
reduced by approximately forty-two percent by removing lines of data designated as 
“unplanned troubleshooting and repair”. The remaining 187 lines of data were broken 
down by six subsystems for model development including: 

- APU 

Electric Power Distribution 
Fuel Cell Systems (FCP) 

Hydraulic Systems 
Orbiter Electrical 

Orbiter Test Conductor Operations 

Though start and finish data was provided, it was unclear if this resulted from a physical 
or resource constraint. Therefore, unless obvious precedence is observed, tasks were 
modeled in parallel. 

The APU is a hydrazine fueled system that provides pressure for the hydraulic 
system. Hydrazine, a toxic liquid, requires special handling during the recycling process. 
Toxic vapor checks are required to determine if repair is required. This system is 
inspected at the OPF; however, the repair is accomplished at the HMF. Following repair, 
the APU system is returned to the OPF for installation and leak functional testing. 

The FCP system generates power for the orbital electrical system. The activities 
within this part of the module include testing the power reactant storage and distribution 
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system (stores and distributes oxygen & hydrogen reactants to fuel cells) and servicing of 
the waste spray boiler (WSB) used to cool the APU system. 

The recycling of the hydraulic systems begins with the inspection of the hydraulic 
system, including the checkout and servicing of the WSB used to cool the hydraulic 
system. Following servicing of the hydraulic system, the system is powered up for the 
functional checkout of the circulation pumps, flight control system, SSME, OMS, nose 
landing gear, and hydraulic brake systems. 
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Figure 15. Power Management 


3.5 Propulsion 

Development of the Propulsion module was based primarily upon data documented in the 
OPF_dB_STS81_LbrClrs excel spreadsheet. The initial 230 lines of data were initially 
reduced by approximately thirty-three percent by removing lines of data designated as 
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“unplanned troubleshooting and repair.” The remaining 165 lines of data were broken 
down by five subsystems for model development including: 

Shuttle Main Engines (SME) 

Ground Support Equipment 
- OMS 

Main Propulsion System (MPS) 

Nondestructive Evaluation 

Though start and finish data was provided, it was unclear if this resulted from a physical 
or resource constraint. Therefore, unless obvious precedence is observed, tasks were 
modeled in parallel. The exception to this analysis methodology was the SME module 
which was based upon the data provided in a NASA Report (Christenson & Komar 1998: 
50-59). Data provided in this report included not only start and finish data, but also 
precedences. The SME must be removed, inspected, and repaired between each flight. 
Therefore, the conceptual model propulsion model is broke into three sections; activities 
that occur from OPF roll-in to SME removal, engine repair, and SME installation to OPF 
roll-out. 

Following OPF roll-in, the SME is dried and inspected, the heat shield removed, 
and the low pressure pump torque is checked. The MPS lines are checked, protective 
covers installed, leak and function tests are performed. The OMS subsystem is safed, 
deserviced, and inspected. Approximately 12% of these inspections result in a need for 
repair/servicing of the OMS pods. Similarly, 38% of these inspections result in a need 
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for repair/serving of the FRCS. The repair of the OMS and FRCS is hazardous, 


therefore, if the OMS and FRCS require repair, they are sent to HMF. 


Once the SSMEs are removed, they are taken to the OMEMF and serviced. 


Figure 16 provides the flow at this level. 



Figure 16. OMEMF 

In the event that a new engine would be used, the process flow would be quite 
different much simpler than that of the existing engines. Figure 17 provides the 
schematic for this level of decomposition. 
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Figure 17. Existing Engine 


When a replacement engine enters the OPF, it is inspected prior to installation. 
The engine is installed and integrated with the MPS. SME/MPS integration is tested, the 
engine and dome mounted heat shields are installed, the gimbal clearance is checked, and 
the SME inspected prior to OPF roll-out. 

3.6 Safety Management and Control 

Development of the Safety Management & Control module was based primarily 
upon data documented in the OPF_dB_STS81_LbrClrs excel spreadsheet. The sole 
subsystem in this “design discipline” is the Purge, Vent, and Duct system. This system 
supports systems within unpressurized compartments by: 
gas purge for thermal conditioning 
prevent accumulation of hazardous gases 
provide venting during ascent and reentry, 
drain trapped fluids, 

condition window cavities to maintain visibility. 
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3.7 Structures, Mechanisms, and Vehicle Handling 
Development of the Structures, Mechanisms, and Vehicle Handling module was based 

upon data documented in the OPF_dB_STS81_LbrClrs excel spreadsheet. The initial 

405 lines of data were initially reduced by approximately twenty-four percent by 

removing lines of data designated as “unplanned troubleshooting and repair”. The 

remaining 309 lines of data were broken down by nine subsystems for model 

development including: 

Ground Support Equipment 

Mechanism 

Nondestructive Evaluation 
Orbiter Handling Equipment 
Forward Panel Repair 
Pyrotechnic Systems 
Quality Engineering 
Orbiter Structures 
- VPL 

Though start and finish data was provided, it was unclear if this resulted from a 
physical or resource constraint. Therefore, unless obvious precedence is observed, tasks 
were modeled in parallel. 

The Mechanism subsystem includes such systems as the orbiter docking system, 
main landing gear assembly, nose landing gear assembly, and external tank door 
operations. Each of these systems are inspected, and checked for leaks and function. 

For example, the orbiter docking system was initially designed to dock with the Russian 
Mir space station, but is now used to dock with the International Space Station. The 
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recycling process requires an inspection of the vestibule and an internal/external post 
flight inspection. If all is in working condition, a protective cover is installed and the 
docking mechanism undergoes a functional check. 

The structure of the orbiter is also inspected, repaired, and checked out as part of 
the recycling process. Of interest in this area are the windows which must be inspected, 
polished, and sometimes removed and repaired. A vast majority of the “unplanned 
troubleshooting and repair” noted above is to the structure of the orbiter. 


67 




Figure 18. Structures, Mechanisms, and Vehicle Handling 
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3.8 TPS Processing 

There are several forms of thermal protection on the orbiter. These items are 
either stored after delivery or manufactured at KSC. The most time consuming part of 
the TPS is the orbiter tiles, which are manufactured individually by hand or by machine. 
Each tile has a specific place on the orbiter and is not interchangeable. Servicing the TPS 
on the orbiter begins with a walk down inspection on the runway after landing. Once the 
orbiter is in the OPF, the inspection of the TPS begins and is broken into various hard to 
define groups. The inspection and maintenance of TPS components is an ongoing 
process throughout much of the OPF processing time. Therefore, the TPS procedures 
were not modeled moment by moment but rather by procedure beginning with the 
inspections. 

There are eight components that make up the TPS each having subcomponents 
with various levels of inspection required. The main components of the TPS are as 
follows: 

- Reusable Surface Insulation (RSI) Tiles 

- Advanced Flexible Reusable Surface Insulation (AFRSI) Blankets 

- Felt Reusable Surface Insulation (FRSI) 

- Reinforced Carbon-Carbon (RCC) 

- Gap Fillers 

- Thermal Barriers 

- Thermal Seals 

- Window Thermal Panes 

Depending on the location on the orbiter and the type of material, the item will either 
receive a macro-level or micro-level inspection. The macro-level inspection is 


69 



accomplished at a distance of 3 to 5 feet and is a visual inspection looking for major 
inspections. In some cases, the macro-level inspection is a precursor to a more detailed 
micro-level inspection possibly requiring specialized equipment and is primarily a hands- 
on inspection. These inspections are further divided by 10 areas on the orbiter. For this 
model, it was decided to group the inspections by these 10 areas when modeling the 
inspections. Since the inspections can occur in any order and maintenance may begin 
before all the inspections are complete, the model allows for the inspections and 
maintenance activities to be performed in parallel as seen in Figure 19. 



Figure 19. TPS Processing 
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Within the data concerning TPS maintenance falls the reworking of payload bay 
door (PLBD) hinges and the orbiter drag chute used during landing to help slow the 
orbiter down so the breaks may be used. During various operations, it may be necessary 
to install protective pads on the wings of the orbiter so this task is modeled in parallel to 
the inspection and maintenance activities allowing for the operation to occur as needed. 
Additionally, the RSI tiles and FRSI must be rewaterproofed before each launch. The 
waterproofing process makes the components hygrophobic (Gordon 1995). This process 
keeps the components from taking on water and increasing weight and reduces the 
possibility of damage. Since the waterproofing compound is hazardous, the 
waterproofing operations are generally conducted on the third shift when no one else is 
present. Those performing the waterproofing operations must where protective suits. 

Much of the TPS is manufactured or assembled on site at KSC within the TPS 
Facility. The components with more detailed operations were modeled with more detail 
while others were included with only a description rather than a full decomposition. The 
most detailed operation is for the RSI tiles as seen in Figure 20. 
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Figure 20. RSI Tile Maintenance 

The orbiter contains almost 20,000 RSI tiles of which 96 on average require 
replacement and 1,800 require repair. Tile replacement requires the greatest amount of 
time for TPS maintenance taking up to 60% of the total TPS man-hours. Inspections 
require 10% of the time, gap filler maintenance uses 22% of the time, and the rest is 
divided among the other components (Livingston and Rooney 2003). A major process 
that eats up much of the tile replacement time is tile manufacturing. It is clear that any 
new system using a different TPS system could potentially reduce processing time 
considerably. 

Each tile is unique and requires machining form a tile blank that is produced on 
site at KSC. The tile can be made form a computer file or from a physical mockup made 
from the space it was removed from. In some cases, the physical model is digitized and 
manufactured on a numerically controlled machine the same as those using a computer 
file. Although the model allows for rework after pre-fit, the tiles made by hand require 
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more time and generate more rework and scrap which is not detailed in the model. Each 
of the two pre-fits is conducted by taking the tile to the OPF and fitting it on the orbiter. 
As a result of the pre-fit procedures, the TPS Facility is located near the OPF to help 
reduce the time needed for tile replacement. Figure 21 contains the decomposition for 
RSI Tile manufacturing. 
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Figure 21. RSI Tile Manufacturing 

4.0 Transport Orbiter from OPF to VAB 

After OPF processing is complete and post inspections are good, the orbiter is 
transferred to the VAB. To transfer the orbiter to the VAB, the Orbiter Transport System 
is used rather than towing the orbiter on its wheels; the orbiter’s landing gear is closed 
and sealed until extended for landing. The transportation process takes approximately 1 
day to complete. 

5.0 VAB 

The VAB is where the SRBs are assembled, the ET is stored and processed, and 
the shuttle components are mated to each other on top of the MFP. The VAB was 
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originally built to support the Saturn V rocket and is thus a very large facility with four 
bays. Two bays are used for mating operations the other two contain one storage and one 
checkout cell each for ET processing. Additionally, one of the latter bays may be used 
for temporary protection of the shuttle assembly from inclement weather—such as a 
hurricane. The VAB is designed to withstand winds up to 125 MPH. 

The mating process generally involves the MLP being placed in one of two bays. 
Then the SRBs are attached to the MLP. Next, the ET is mated to the SRBs but not to the 
MLP; the SRBs will be the only objects mated to the MLP and will support all the 
weight. The last major operation is the mating of the orbiter. This procedure is quite 
delicate since the facility was not designed for this operation. The overhead crane system 
is used to lift the orbiter and pass it at just the right angle through several support 
structures until it is in the appropriate bay. Then the orbiter is put into its place. The 
mating of all components takes approximately 1 week to complete. Other operations in 
the VAB surround the processing of SRBs and ETs. 
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Figure 22. VAB 
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Although final SRB assembly occurs in the VAB, most of the SRB operations 
occur in the nearby Rotation, Processing, and Surge Facility (RPSF). The RPSF contains 
three structures: processing facility, support building, and storage building. The 
processing building is used for receiving, inspecting, segment rotation, and aft booster 
buildup. The storage building can store up to eight segments or two boosters. The 
operations within the RPSF are considered hazardous since the boosters contain live solid 
rocket fuel. When the segments are ready, they are transported to the VAB for stacking 
as previously described. 



Figure 23. SRB Operations in the RPSF 
6.0 Transport Shuttle to Launch Pad 

The integrated shuttle including orbiter, SRBs, and ET atop the MLP are 
transported to the launch pad mounted to one of the crawler/transporters. The crawler 
transporter is driven into the bay containing the integrated shuttle and is lifted until the 
MLP is taken off its supports. The entire assembly then begins the 8 hour drive to one of 
two launch pads. The crawler/transporter follows a 130 foot wide track containing two 
40 foot wide gravel paths separated by a 50 foot median. Once at the launch pad, the 
crawler/transporter lowers itself and lets the MLP rest on the supports at the launch pad. 
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The crawler/transporter is then removed to a safe distance but kept nearby. If bad 
weather is expected, the shuttle assembly can be taken back to an open bay in the VAB 
for protection. 

7.0 Launch Pad Ops 

The launch pad is where the launch takes place, final testing of systems occurs, 
vertical and hazardous payloads are installed, and liquid fuel is loaded into the ET. There 
are two launch pads used for the shuttle. The launch pads are approximately 3-4 miles 
from the VAB and are on the coast allowing for launches to take place over the water. 
This allows for the SRBs to be dropped into and later recovered from the ocean. 

Activities that are hazardous or inherently dangerous are held off until the last 
moment they can occur. The launch pad is where many of these operations are 
conducted. The liquid propellant for the ET is pumped in and the hypergolic fuel for the 
FRCS, APU, and OMS pods uploaded. Ordinance devices are installed and activated on 
the launch pad to limit the opportunity for premature discharging. 

Additional activities include the inspection of connections and lines to include the 
X-raying of the SSME hydraulic quick disconnects. The TPS is inspected where it is 
adjacent to moving components and on doors for proper seal. The ET is inspected for ice 
buildup to determine any potential hazards for the orbiter. Also, the cryogenic propellant 
lines are sprayed to prevent ice buildup. Lastly, any hazardous or vertically integrated 
payload is loaded into the payload bay while the shuttle is on the launch pad. Generally, 
satellites are vertically integrated. The model for launch pad operations can be seen in 
Figure 24. 
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Figure 24. Launch Pad Operations 


MLP refurbishment facility 

The MLP is refurbished after each launch and is reused. This MLP goes from this 
facility to the VAB where the shuttle assembly is mated to it and then is delivered to one 
of the launch pads. The MLP with or without the shuttle assembly is transported on one 
of two crawler transporters which are another left over item from the APOLLO space 
program. 

8.0 SRB Recovery 

The SRBs touchdown within minutes after launch. However, before touchdown, 
the first set of parachutes is deployed form the frustrum to slow the descent. Then the 
frustrum is separated from the rest of the SRB and the main chute is deployed. The SRB 
lands in the water vertically and stays afloat due to water trapped inside. In addition, a 
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strobe and homing beacon are used to aid in locating each SRB. Each frustrum and 
parachute is retrieved and then the parachute for each SRB. The SRBs are towed back to 
the dock where they are taken to the RPSF for processing. After processing, the SRBs 
are shipped via rail to Utah where they are refurbished. Since there are two ships 
available for recovery, each frustrum and SRB pair can be retrieved in parallel as 
opposed to the model in Figure 25. 



Figure 25. SRB Recovery Operations 

Validation and Verification 

A conceptual model is the “basis for judgment about a simulation’s capabilities in 
conditions” for which it was not tested (Pace 2000). The key to achieving such 
compatibility and reliability in simulation data is the simulation conceptual model 
because the simulation conceptual model is the basis for judgment about the 
appropriateness (validity evaluation) of simulation data for all conditions not specifically 
tested. When a model is nearing completion, it requires analysis. 
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The evaluation criteria are completeness, consistency, coherence, and correctness 
(Pace 2000). Completeness refers to addressing all entities and processes within the 
domain and all components of the simulation space while satisfying the specification of 
the simulation. Consistency ensures the entities and processes are addressed from 
compatible perspectives. Coherence checks to see if all elements have a function and all 
elements can be activated. The last criterion, correctness, is more general in nature and 
refers to an overall review of the model for flow and understanding (Pace 2000). 

Verification comes in part from the comparison of the completed model to the 
requirements set forth in Chapter 3. The model was examined and an element was found 
for every item specified for representation. Furthermore elements of potential interest to 
the model purpose were addressed indicating a high level of model completeness and 
coherence. Real world counterparts exist for each element enabling reuse and 
unnecessary elements were scrubbed. Additionally, each element is addressed from the 
same perspective. Activities were presented from a process oriented viewpoint and 
entities from an object oriented viewpoint adding to the consistency of the model. Lastly, 
correctness is ensured by checking the overall flow of the model looking for logical flows 
while ensuring no disconnects exist. 

The validation process began by comparing the results of the data analysis 
methodology to similar results generated by NASA personnel. Taking the filtered data 
and importing it to MS Project and developing a IDEF3 schematic, a comparison was 
made. The results were found to be very close confirming the concept of using the start 
and stop dates/times to establish precedence where none was given. By comparing 
NASA flow diagrams to the IDEF3 model, the data analysis method was validated. 
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V. Conclusions and Recommendations 


In this chapter, conclusions, recommendations, and suggestions for future 
research will be discussed. This chapter will also re-examine the scope and limitations, 
then look at the threats to validity that were suggested at the beginning of the analysis, 
and see what materialized to see if any unforeseen conditions arose. 

Conclusions 

Beginning the modeling process with a detailed conceptual model is the most 
appropriate step. By working at the Domain Level, the baseline concepts and flows can 
be gathered providing insight into the data required and the data currently available. This 
step allows the researcher to gather facts about the system to be modeled and combine 
them into a format that is clear and concise. 

Using the IDEF3 methodology provided an excellent format for organizing the 
data and presenting it in a clear model. The use of a few basic components made learning 
the methodology quick and easy. The IDEF3 methodology matches well with conceptual 
model development and is just right for the layout of process-centered diagrams. 
Additionally, it adds the capability to diagram object-centered views. 

The use of KBSI’s ProSim 7.0 provided several benefits. The software was easy 
to grasp and allowed for the collection of and transformation of the data directly into a 
IDEF3 schematic. The interface was user-friendly and provided several ways to view the 
data. When viewing the data in the Process Flow Node Fist mode, each diagram and 
block was represented by a single line of text on the screen. Each decomposition could 
be opened or closed by expanding or collapsing the tree. In this mode, it was easy to 
move objects around the model. Another benefit is the generation of the model in HTMF 
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format. ProSim generates a folder that contains the model components as individual 
HTML files that can be opened and viewed on any web browser. This function allows 
the model to be shared with others who do not have the ProSim software. 

An additional benefit of the ProSim software not realized in this effort is its 
ability to integrate simulation data and be used to conduct analysis. ProSim was designed 
to not only produce IDEF3 schematics but to be used to conduct simulation analysis. 

How well ProSim operates in this capacity or whether it would be appropriate for use in 
future research in this endeavor is unknown at this point. 

Scope and Limitations 

Data as expected turned out to be a limitation and provided a challenge for the 
scope. In some cases, the data was too detailed but still lacking in levels of precedence. 

In many cases the data was found to be difficult to track down. Data concerning 
operations outside the OPF was especially difficult to locate. Data outside the scope of 
the effort had to be filtered out based on the judgment of the researcher. Additionally, the 
bias and interest of those at KSC influenced this problem to some degree. Three main 
ongoing concerns at KSC concern the SSMEs, TPS, and unscheduled maintenance. The 
first two generated the data that was in greater detail while the last item generated data 
that was outside the scope. 

Threats to Validity 

Due to the above listed focus at KSC, time and resources have been devoted to 
collecting data associated with those areas of concern rather than all operations. 
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Therefore, data concerning engine operations, especially within the OPF, and the TPS 
exists in detailed and extensive quantities. A list of 5988 STS procedures was provided 
to the researchers. Of the 425 different STS procedures used to develop the current 
conceptual model, only 70% were found in this list. 

Additionally, much data exists for unscheduled maintenance and the associated 
troubleshooting. KSC spends approximately 25% of shuttle turnaround time on 
unscheduled maintenance (McCleskey 2003). The importance of analyzing unscheduled 
maintenance for trends is seen in the possibility of discovering tasks that should be 
performed more often that may be necessary to reduce both future maintenance actions 
and turnaround time. These tasks are not included in this model. Some activities of 
concern to developers of next generation space vehicles may have been inadvertently left 
out since those tasks are not regularly scheduled or recognized as needing to be 
scheduled. 

Data Analysis 

The most difficult data to analyze was the data found in spreadsheets and tables. 
The spreadsheets allowed sorting by design disciplines, STS subsystems and procedure 
numbers. However, lack of textual description of the process or overall procedure 
(including constraint information) made model developing challenging. The researcher 
was left to arrange the data based on the known constraints (remove must occur before 
installation) and task timing (start and finish times). Without the benefit of process 
descriptions and constraints, many processes were modeled in parallel. 


82 



Using the supplied data, this research did serve in verifying that the methodology 
used to filter and scrub the data was correct. The key here was to develop a baseline 
model encompassing the necessary activities of a general nature that may be useful in 
developing a simulation for RSV ground operations. This model serves that purpose and 
is useful in understanding the processes involved in turning around a RSV. The level of 
data available was useful in this initial baseline approach but will need to be expanded for 
research to continue. 

Suggestions for Further Study 

This research effort exposed the need for further data collection and 
decomposition. The data sets examined to gain a baseline understanding of the 
operations at KSC are not sufficient enough to provide the detail needed for developing 
distributions about the durations and arrival rates needed for simulation development. 
Continued research into the collection of this data and its analysis would be beneficial to 
the furtherance of this effort towards the development of a simulation. 

However, this effort was tasked with developing a baseline conceptual model that 
would be used to model various SOVs making tradeoffs between components and 
materials. With this end in mind, it may not be necessary to collect detailed data on all 
aspects of the shuttle operations, but only those deemed necessary by subject matter 
experts. 

Additionally, continued research into unscheduled maintenance on the shuttle 
would be beneficial in providing greater validity to the model. By filtering out the data 
without further examination, some necessary model components may not have been 
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modeled simply because they were not scheduled. A detailed examination of the 
unscheduled maintenance on the shuttle may expose those activities that should have 
been included and provide a more rigorous method for filtering out unnecessary data. 
Appendix C contains a more detailed listing of further research. 
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Appendix A: Listing of Acronyms Used in Model 


Due to space constraints and the time consuming nature of data entry, many items 
names have been replaced with acronyms. In the body of the document, the item name is 
spelled out for the first use but that is not the case for the model. To help in 


understanding the model, this list of items and corresponding acronyms has been 
developed. 


AFRSI 

advance flexible reusable surface insulation 

APS 

auxiliary power system 

APU 

auxiliary power unit 

AV 

avionics 

C/O 

check out 

CCTV 

closed circuit television 

CEIT 

crew equipment interface test 

COMM 

communication 

DPS 

data processing system 

ECLSS 

environmental control life support system 

ECS 

environmental control system 

EPD 

electronic power distribution 

ET 

external tank 

ET 

external tank 

FCP 

fuel cell systems 

FCS 

flight control system 

FRCS 

forward reaction control system 

GH2 

gaseous hydrogen 

GHE 

ground handling equipment 

GNC 

guidance, navigation, and control 

GOX 

gaseous oxygen 

GPS 

global positioning system 

GSE 

ground system equipment 

HMF 

hypergol maintenance facility 

HPFTP 

high pressure fuel turbo pump 
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HPOTP 

high pressure oxidizer turbo pump 

HUD 

heads up display 

HYD 

hydraulic systems 

INS 

instrumentation system 

KSC 

Kennedy Space Center 

LESS 

leading edge structural system 

LH2 

liquid hydrogen 

L02 

liquid oxygen 

LP 

launch pad 

LPFTP 

low pressure fuel turbo pump 

LPOTP 

low pressure oxidizer turbo pump 

LPS 

launch processing system 

MEDS 

multifunction electronic display system 

MCC 

Mission Control Center 

MEQ 

mechanism 

MLG 

main landing gear 

MLGD 

main landing gear door 

MLP 

mobile launch pad 

MPS 

main propulsion system 

MSBLS 

microwave scanning beam landing system 

MTU 

master timing unit 

NC 

numerical control 

NDE 

nondestructive evaluation 

NLG 

nose landing gear 

NLGD 

nose landing gear door 

ODS 

orbiter docking system 

OEL 

orbiter electrical 

OHE 

orbiter handling equipment 

OME 

orbiter maneuvering engine 

OMEF 

orbiter main engine maintenance facility 

OMEMF 

orbiter main engine maintenance facility 

OML 

outer mold line 

OMS 

orbiter maneuvering system 

OPF 

orbiter processing facility 

OPS 

operations 

OSO 

orbiter support ops 

OTC 

orbiter conductor operations 

PCMMU 

post code master modulation unit 

PLBD 

payload bay door 

PRSD 

power reactant storage and distribution 

PVD 

purge, vent, and drain 

PYR 

pyrotechnics 
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QC 

quality engineering 

R&R 

remove and replace 

RCC 

reinforced carbon-carbon 

RCS 

reaction control system 

RPSF 

rotation, processing, and surge facility 

RSI 

reusable surface insulation 

SCOPALS 

scanner closeout preprocessor and lofting system 

SME 

shuttle main engine 

SRB 

solid rocket booster 

SSME 

space shuttle main engine 

SSME 

space shuttle main engine 

STR 

structures 

TCID 

test configuration identifier document 

TPS 

thermal protection system 

TVC 

thrust vector control 

VAB 

vehicle assembly building 

WCS 

waste collection system 

WSB 

waste spray boiler 

XDUCER 

crossducer 
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Appendix B: Baseline Conceptual Model for RSV Ground Ops 


This section includes all the diagrams included in the model in the order 
generated by ProSim when exported as a RTF document. The RTF was then converted to 
a MS Word document and imported into this thesis. This collection of diagrams is meant 
to aid in understanding the model by providing a physical versus electronic version. This 
collection of diagrams is meant to supplement the electronic version of the model and is 
not intended to replace it. The electronic version is made available with this document to 
aid in further research efforts and model development. 
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Figure B-l. Overarching Shuttle 


Description 

There are thousands of activities performed during the course of a normal OPF processing flow. 
For the most part, these can be grouped into the following three major activities: Preparing the 
external surfaces (e.g. the thermal protective tiles) for the next mission. Because of improvements 
in tile repair and manufacturing processes, along with modifications to the thermal protection 
system, this work is not typically the critical path. 

Payload related work in the Orbiter’s mid-body or payload bay and crew cabin. This activity 
includes downloading the previous mission payload and its integration hardware, and preparing 
the payload bay and crew cabin for the upcoming payload. This activity is typically either the 
critical path or at least a major influence on the critical path. 

Work in and around the Orbiter’s Aft Engine Compartment. This activity includes, safing the 
OMS Pods and Auxiliary Power Units, removing the three main engines, installing the next set of 
engines and performing pre-flight testing of the Aft Engine Compartment’s many systems. Like 
the payload related work, this activity is either the critical path or a major influence. 

Not mentioned above are many other important tasks that must be integrated into the flow such as: 
safing the FRCS , changing the tires; polishing the windows; trouble-shooting the previous 
mission’s in-flight problems and a host of minor problems that occur during the course of any 
OPF flow; and performing approved modifications. (Cates Shuttle Processing Overview.ppt) 

Orbiter Processing Facility (OPF) 

There are three OPF high-bays available for Orbiter Processing. These are referred to as Bay 1, 
Bay 2, and Bay 3. Bays 1 & 2 are co-located and Bay 3 is located a short distance from them. 

The orbiter processing flow begins at OPF roll-in and ends at OPF roll-out to the Vehicle 
Assembly Building. The orbiter is processed in one of the three OPF bays for approximately 80 
Calendar days (62 Workdays) of OPF Processing. 
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Figure B-2. Element L&R Ops 



Figure B-3. Launch Pad Ops 


90 

















Figure B-5. Post-Flight Ground Handling 
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Figure B-8. System Shutdown, Safing, and C/O 



Figure B-9. SSME Processing @ LP 
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Figure B-12. Ground Systems & Facilities 
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Figure B-13. Payload Accommodations 
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Figure B-16. Safety Management & Control 
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Figure B-17. Structures, Mechanisms, Vehicle Handling 






Figure B-18. TPS Processing 



Figure B-19. ET OPs 



Figure B-20. Orbiter Mating 












Figure B-21. SRB Ops 



Figure B-22. SSME FRTs 



Figure B-23. Cockpit & Crew Panel 
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Figure B-24. Command Control & Health Management 
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Figure B-26. Environmental Control & Life Support 
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Figure B-27. GNC 



Figure B-28. APU 



Figure B-29. FCP 
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Figure B-30. HYD 
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Figure B-33. MPS 


108 











Figure B-34. OMS 
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Figure B-35. SSME 



Figure B-36. MEQ 
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Figure B-37. STR 



Figure B-38. PYR 



Figure B-39. YPL 
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Figure B-40. TPS Maintenance 









Figure B-41. Post Flight Inspections 
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Figure B-42. Orbiter Mating Ops 



Figure B-43. Inspect Completed SRB 



Figure B-44. RPSF 



Figure B-45. Data Processing System (DPS) 
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Figure B-46. INS 



Figure B-47. KU Band 
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Figure B-49. ECLSS 


Install Fan 
Package 

_w. 

Fan Package 
Flow Test 

r 

3.1.2.1.1 

3.1.2.1.2 


Figure B-50. Fan Package 



Figure B-51. NLG Ops 
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Figure B-51. GSE SME Install to exit 



Figure B-52. GSE to SSME Removal 



Figure B-53. MPS to SME Removal 
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Figure B.54. MPS SME Install to Roll-out 



Figure B-55. OMS Pods 



Figure B-56. OMS to SME Removal 
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Figure B-57. OMS Post SME Installation 



Figure B-58. Engine Installation to OPF Roll-Out 



Figure B-59. OMEF 
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Figure B-60. OPF Roll-In to SSME Removal 



Figure B-61. ET Door Operations 



Figure B-61. MLG Assembly 



Figure B-62. NLG Assembly 
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Figure B-63. ODS Inspections 



Figure B-64. Corrosion 
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Figure B-65. Windows 



Figure B-66. AFRSI Blanket Maintenance 
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Figure B-67. FRSI Maintenance 



Figure B-68. Tile Replacement 



Figure B-69. Windows 
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Figure B-70. Lower Aft Fuselage 



Figure B-71. Lower Forward Fuselage 
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Figure B-72. Lower Midbody Fuselage 
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Figure B-74. Lower Wing 



Figure B-75. OMS Pods 



Figure B-76. Upper Aft Fuselage 
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Figure B-77. Upper Forward Fuselage 



Figure B-78. Upper Midbody Fuselage 



Figure B-79. Upper Wing 
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Figure B-80. Vertical Stabilizer 



Figure B-81. MPS Leak & Functional 



Figure B-82. Monitoring 
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Figure B-83. Monitoring Functions 



Figure B-84. Engine Installation Operations 



Figure B-85. Existing Engine 
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Figure B-86. New Engine 



Figure B-87. SSME Removal Operations 



Figure B-88. Make New Tile 



Figure B-89. Lower Aft Fuselage Macro 
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Figure B-90. Lower Aft Fuselage Micro 



Figure B-91. Lower Forward Fuselage Macro 
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Figure B-92. Lower Forward Fuselage Micro 
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Figure B-93. Lower Midbody Fuselage Macro 
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Figure B-94. Lower Midbody Fuselage Micro 
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Figure B-96. Lower Wing 














Figure B-97. OMS Pods Macro 



Figure B-98. OMS Pods Micro 



Figure B-99. Upper Aft Fuselage Macro 
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Figure B-100. Upper Aft Fuselage Micro 



Figure B-101. Upper Forward Fuselage Macro 











Figure B-102. Upper Forward Fuselage Micro 
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Figure B-103. Upper Midbody Fuselage Macro 



Figure B-104. Upper Midbody Fuselage Micro 
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Figure B-105. Upper Wing Macro 



Figure B-106. Upper Wing Micro 









Figure B-107. Vertical Stabilizer Macro 



Figure B-108. Vertical Stabilizer Micro 
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Figure B-109. NC Programming 



Figure B-110. Physical Model 
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Figure B-lll. Orbiter 
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Figure B-114. Tile R&R 
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Appendix C: Future Research 


This appendix seeks to expand upon the future research discussed in Chapter 5. 
This section has been broken into categories with potential areas of analysis listed within 
each. Some of the subcategories can be taken alone or combined for further research. 


Data collection and analysis 

Data is available from several sources. NASA has partnered with various 
agencies such as AFRL and has shared data with them. Within AFRL, several offices 
may have data collected independently of other sources. A listing of each office working 
with space shuttle data would be very helpful. Additionally, the current maintenance 
contract holder, United Space Alliance, would be a good source of information. One of 
the difficulties experienced was asking for the data using the correct terminology; for 
example, what NASA calls a work breakdown structure is not necessarily what the 
researcher has requested. Some areas of future research within this area are as follows: 

- Develop a user friendly information system to capture both component and 
subsystem level logistics information (MTTF, Repair Time, failure rate 
distributions, etc) from research and development through Concept Refinement 
and Technology Development (Milestone B) to enable Simulation Based R&D 
and Simulation Based Acquisition model development. 

- Develop methodology to collect and document component and subsystem level 
logistics information (MTTF, Repair Time, failure rate distributions, etc) from 
past, present and future reusable space vehicle operations to enable Simulation 
Based R&D and Simulation Based Acquisition model development. 

- Identify, quantify, and incorporate into conceptual model space shuttle’s 
“unscheduled/troubleshooting” activities (propulsion, power management, 
thermal protection, etc...). 
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System Comparisons 


The space shuttle is not the only vehicle to be used as a baseline. Therefore it is 
necessary to look at the other baselines on the aircraft side of the spectrum. Also, any 
simulations existing for aircraft systems would be of interest and should be examined. 
Another area of interest would be the logistics surrounding expendable launch vehicles 
(ELY). 


- Compare and contrast the ground facility/logistics requirements for rocket and air- 
breathing propulsion systems for use on reusable space vehicles (maintenance, 
fuel, etc...). 

- Compare and contrast the ground facility /logistics requirements for current and 
potential future thermal protection systems. 

- Investigate the difference in logistics/maintenance requirements for manned and 
unmanned reusable launch vehicles. 

- Investigate the ground facility/logistics requirements for the aircraft selected as 
the baseline. Locate and analyze any existing simulations. 

- Investigate the ground facility/logistics requirements for ELVs. Locate and 
analyze any existing simulations. 

Simulation Generation 

- Develop simulation modules for “design disciplines” identified in this document 
(propulsion, power management, thermal protection, etc...) based upon 
planned/scheduled maintenance. 

- Develop simulation modules for “design disciplines” identified in this document 
(propulsion, power management, thermal protection, etc...) based upon 
unscheduled/troubleshooting activities. 


Investigate other simulations 

- Compare and contrast simulations under development by NASA, AFRL, and 
other government agencies. Examine modules included, level of detail, and 
reasoning behind development. Look for level of detail, systems included, and 
precedence/flow logic. Then compare to the baseline conceptual model in this 
research and to the simulations being investigated. 

Compare and contrast NASA’s Shuttle Op’s 1.0 to existing AFRL and 
contractor simulations. 
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